Skip to content

Conversation

wanx7130
Copy link

@wanx7130 wanx7130 commented Oct 6, 2025

Purpose

Test Plan

Test Result


Essential Elements of an Effective PR Description Checklist
  • The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
  • The test plan, such as providing test command.
  • The test results, such as pasting the results comparison before and after, or e2e results
  • (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
  • (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

Copy link

github-actions bot commented Oct 6, 2025

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of those by going to your fastcheck build on Buildkite UI (linked in the PR checks section) and unblock them. If you do not have permission to unblock, ping simon-mo or khluu to add you in our Buildkite org.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

🚀

@mergify mergify bot mentioned this pull request Oct 6, 2025
5 tasks
Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Comment on lines 637 to 643
def _handle_client_request(self, request_type: EngineCoreRequestType,
request: Any) -> None:
"""Dispatch request from client."""

logger.info("[wxl debug] EngineCore handling client request %s.", request.request_id)
if request_type == EngineCoreRequestType.ADD:
self.add_request(request)
elif request_type == EngineCoreRequestType.ABORT:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P0 Badge Abort requests crash when logging request_id

The new info log dereferences request.request_id before inspecting the request type. When an abort is submitted the request argument is a list[str] of request IDs (see the ABORT branch immediately below), so this line raises AttributeError and prevents _handle_client_request from reaching self.abort_requests. Any client attempting to cancel a request will now crash the engine core loop. Guard the log by checking the request type or by logging the value without assuming a request_id attribute.

Useful? React with 👍 / 👎.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces several logging statements for request tracing. While adding logs is beneficial for debugging, many of the new logs are at the INFO level and contain a [wxl debug] prefix, indicating they are temporary and not suitable for a production environment. These should be removed before merging. Additionally, some existing DEBUG logs have been promoted to INFO level in performance-sensitive areas, which could lead to excessive logging and performance degradation. These should be reverted to DEBUG level.

Comment on lines +346 to +347
logger.info("[wxl debug] %s has already received kvcache and enter into waiting status.",
request.request_id)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

This log message appears to be for debugging purposes, as indicated by the [wxl debug] prefix. Such temporary debugging code should be removed before merging into the main branch to avoid cluttering production logs.

Comment on lines +349 to 351
logger.info(
"[wxl debug] %s is still in WAITING_FOR_REMOTE_KVS state.",
request.request_id)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

This log message appears to be for debugging purposes, as indicated by the [wxl debug] prefix, and has been elevated from DEBUG to INFO level. This change could lead to excessive logging in production. It should be reverted to the original DEBUG level and the debug prefix should be removed.

Suggested change
logger.info(
"[wxl debug] %s is still in WAITING_FOR_REMOTE_KVS state.",
request.request_id)
logger.debug(
"%s is still in WAITING_FOR_REMOTE_KVS state.",
request.request_id)

) -> RequestOutputCollector:
"""Add new request to the AsyncLLM."""

logger.info("[wxl debug] Request %s start add_request.", request_id)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

This log message appears to be for debugging purposes, as indicated by the [wxl debug] prefix. Such temporary debugging code should be removed before merging into the main branch to avoid cluttering production logs.

"""

try:
logger.info("[wxl debug] Request %s start generate.", request_id)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

This log message appears to be for debugging purposes, as indicated by the [wxl debug] prefix. Such temporary debugging code should be removed before merging into the main branch to avoid cluttering production logs.

request: Any) -> None:
"""Dispatch request from client."""

logger.info("[wxl debug] EngineCore handling client request %s.", request.request_id)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

This log message appears to be for debugging purposes, as indicated by the [wxl debug] prefix. Such temporary debugging code should be removed before merging into the main branch to avoid cluttering production logs.

self._update_stats_from_finished(req_state, finish_reason,
iteration_stats)

logger.info("[wxl debug] Request %s outputprocessor processed output and will return to client.", req_id)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

This log message appears to be for debugging purposes, as indicated by the [wxl debug] prefix. Such temporary debugging code should be removed before merging into the main branch to avoid cluttering production logs.

data_parallel_rank: Optional[int] = None,
) -> tuple[Optional[str], EngineCoreRequest]:

logger.info("[wxl debug] Request %s start process_inputs.", request_id)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

This log message appears to be for debugging purposes, as indicated by the [wxl debug] prefix. Such temporary debugging code should be removed before merging into the main branch to avoid cluttering production logs.

Comment on lines +907 to +909
logger.info(
"Transfer KVCache for req %s has completed with handle %s",
req_id, handle)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

This informational log is inside a loop that iterates over transfer handles. In a production environment with many transfers, this could lead to excessive logging and performance degradation. Please consider changing this log to the DEBUG level.

Suggested change
logger.info(
"Transfer KVCache for req %s has completed with handle %s",
req_id, handle)
logger.debug(
"Transfer KVCache for req %s has completed with handle %s",
req_id, handle)

Comment on lines +912 to +914
logger.info(
"Transfer KVCache for req %s still in progress with handle %s",
req_id, handle)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

This informational log is inside a loop that iterates over transfer handles. In a production environment with many transfers, this could lead to excessive logging and performance degradation. Please consider changing this log to the DEBUG level.

Suggested change
logger.info(
"Transfer KVCache for req %s still in progress with handle %s",
req_id, handle)
logger.debug(
"Transfer KVCache for req %s still in progress with handle %s",
req_id, handle)

for req_id, meta in metadata.requests.items():
remote_engine_id = meta.remote_engine_id
logger.debug(
logger.info(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

Changing this log from DEBUG to INFO could result in verbose logging in production, as start_load_kv is called frequently. This might impact performance. It's recommended to revert this to DEBUG level.

Suggested change
logger.info(
logger.debug(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant